"The ability for programs to communicate is a core tenet for the way we want Longhorn to work," said Box. But, he said, object-oriented programming is just not all it was made out to be. "What promised in the 90s to be the most promising technology turned out not to be. By the 1990s, no one disputed that we could make objects work as an industry, but we got carried away with the metaphor. We naively said 'this notion of objects that seems to pan out so well when writing programs… should work for communications between programs.'"

Object orientation itself is not 100% bad and useless. That isn't what Don from Microsoft is claiming. He recognizes that OO is not as communication oriented as the future will need to be. Inheriting an object is not as important as communicating messages between programs. For example, the entire internet is built around TCP/IP communication messages, NOT object orientation.

I first discovered this when I was building a plug-in system and noticed that the most important part of the plug in system was not objects or procedures, but rather the messages that the plug-ins were sending back to the host. The host needs to receive messages from the plug-in, similar to the way a web browser receives messages from a server. There's no point in designing a message communciation system purely around OO hype - because a messaging system is much simpler than OO. In fact, OO layers can be created on top of the messaging system later.

I'm surprised that Don from Microsoft is so surprised that OO is not all that it is cracked up to be for large complex systems - after all, large complex systems generally communicate a bunch of smaller systems together, to make up one larger system. The communication system of all large systems is always based on messages, or communication signals, not object orientation.

I'm also surprised that Don doesn't note SmallTalk OO. Smalltalk object orientation is actually message based. It is therefore ironic that Don says messaging is more important than OO, and that OO needs to be replaced with messaging. In smalltalk, OO is the messaging. I guess what he means is that a combination of XML and messaging is not really OO - the direction they seem to be headed is messaging through XML instead of messaging through binary communication.

The problem with most distributed object technologies, Box said, is that programs require particular class files or .jar files (referring to Java), or .dll files (Microsoft's own dynamic linked libraries). "We didn't have (a) true arms-length relationship between programs," Box said. "We were putting on an appearance that we did, but the programs had far more intimacy with each other than anyone felt comfortable with."

"How do we discourage unwanted intimacy?" he asked. "The metaphor we're going to use for integrating programs (on Indigo) is service orientation. I can only interact by sending and receiving messages. Message-based (communications) gives more flexibility."

The other reason I'm surprised about Don's comments on OO, is that the entire windows API is based on a messaging system, not just Object Orientation concepts. It shouldn't be news to Don that messaging is most important, while OO or parts of OO are optional. Let's just hope that Microsoft doesn't convert the Windows API into XML - I think they may be trying to solve a problem that doesn't exist if they decide to do that.

I'm not exactly sure how XML is going to solve all the problems of messaging though, since each XML file would have to be locked/unlocked when it is being written to - which is really going to slow the entire OS down. Maybe the CPU's will get faster, to handle this. Although lately the CPU's seem to have stopped at 3Ghz. I haven't seen a computer for sale that is significantly faster than the ones for sale 2 years ago. Whereas 4 years ago computers were doubling in clock speed (400mhz, 800mhz, etc.)

What next: microsoft finds out that XML wasn't the answer, because XML isn't a good scalable solution. Next they implement a database driven operating system? A database driven .NET architecture? What can they think up. Or, maybe they should just continue to wrap the Win API like they have been doing decades.